Two entities communicating in a way not susceptible to eavesdropping or interception is known as secure communication. Secure communication includes means by which people can share information with varying degrees of certainty that third parties cannot intercept. Outsourcing the management of secure communication channels over a network has not been possible because of the risk of leakage and difficulty to remain secure.
The very reason for having secure communication lines is to prevent information leakage. Leakage can occur for many reasons such, but not limited to, inadequate information separation, inferior infra structure policies, failing access restrictions, that leakage cause intellectual property losses, mistrust and monetary losses. Leakage can result in involuntary law infringements, exposure of data that was never meant to be shared, security and business hazards. Leakage might lead to that individuals, groups or even companies and organization could be hurt.
In order to separate information that needs to be protected from leakage that does not need to be protected, a number of actions can be taken. Information that needs to be protected at all stages—during creation, storage, use, transportation and destruction, should be kept as protected as the demands prescribe. Encryption can be a part of the information separation. It is desired to ensure that the infrastructure does not provide back doors, traffic can not be snooped, key gateways or intermediary servers can not be spoofed, data can not be redirected or accessed if it is not intended to be so.
However, the above mentioned actions to be taken are tedious, may be expensive and cumbersome and take a lot of resources, for example extensive hardware and software resources. How far an information owner must go, may be dictated by the directives given for data protection and the consequences for failure to protect this data. When the proper steps are taken, elimination of any possibility of leakage by intentional or unintentional human activities still remains to be taken care of. The leakage may be handled by only giving access to approved personnel, including system and network management.
Only staff that has gone through a certain security clearance can maintain a compound network with components of this security classification. However, this does not prevent the intentional or unintentional human activities indicated. Thus, “secure” networks are not that secure. Virtual Private Networks, VPNs, are not that private and just because data traffic is encrypted over some parts of the network, does not mean that it is encrypted over all parts of the network. Human intervention can be a hard to counter problem.
In one example of a network environment, a company has two offices. The company deals with sensitive information of a certain classification. This information should not be spread since it would hurt the company. However, the two offices need to exchange data in order to fulfil a process flow. There are several ways the company can exchange data, for example by courier; dedicated private lines, such as black fibre; semi open networks, such as MPLS (Multiprotocol label switching); or public networks, such as the Internet. Cryptography may be involved in any of these means. An alternative approach may be a traditional VPN (Virtual Private Network) connection between an office A and an office B, using a non protected carrier net.
Information is in plain text at the office networks (Red Networks) of the office A and the office B, but encrypted in one way or another by means of VPN devices over the transport network (Black Network). The VPN device can be comparatively cheap and cheerful and good enough for a specific task in a rather static environment. Reconfiguration of the VPN devices at the offices A and B may be done with a locally attached console or through a device resident web page accessible from the red net side. It might be possible to log certain events, but on the whole, the device is cumbersome and inflexible and not very manageable. It is definitely unsuitable for anything else than mere point-to-point connections due to the unwieldy management methods for these types of devices.
A communication session according to this configuration may include that data bound from Office A's Red Net to Office B's Red Net is intercepted by the VPN device at Office A's gateway point. The data is encrypted and sent over the Black Network to the corresponding VPN device at Office B. Office B's VPN device decrypts the data and dumps it on Office B's Red Net.
Traffic between Red Net A and Red Net B, traversing the Black Net is protected through cryptographically separated tunnels during the Black Net transfer.
An attacker somewhere on the Black Net could try to intercept packages and decrypt them. The attacker could also try to target the VPN device itself either to break in to it or overloading it. This may lead to that the users may temporarily disconnect the VPN devices on either side of the black net to be able to communicate at all and then intercept unencrypted data streams. Moreover, cheap and cheerful devices also often have a less than outstanding MTBF (Mean Time Between Failure) rating.
In order to make things more manageable, the company might use some sort of administration function. A management software on a computer could be used to manage the proximity VPN device of the Office A and already existing tunnels could be used to manage any remote VPN device on for example the Office B. Key handling, alternatively certificate handling, might be possible to do from the management software on the computer connected to the Office As Red Net.
The entire set-up functions very much like a traditional VPN connection, but since management is centralized, several management functions might be greatly facilitated or even possible to carry out. Depending on the device characteristics and software capabilities, these may include configuration and backup, key- and tunnel handling, incident handling, device performance monitoring/reporting, and management of point-to-multipoint or multipoint to multipoint connection.
Even though a VPN device might be capable of multipoint connections, it is unrealistic to try and set them up without a configuration software and to maintain them without the help of a management system.
Possible attacks might be similar to that of a traditional VPN connection, but since the system is managed in this case, it is now possible to class, identify and localize the attack and based on this information, take appropriate measures.
In order to safely administer the VPN devices, the administrative function needs to have either logical or physical access to the device. Management and remote configurations should always be done from the Red Net network address of the device in order to protect the configuration- and management functions from the Black Net. This means that personnel working with the devices must have clearance to connect to any Red Net that has a VPN device within the area of responsibility for the personnel in question. The organization running Office A and Office B could thus not outsource the management of the VPN devices and tunnels in between them since that would elevate the risk of leakage immensely.
The organization running Office A and Office B and the connection between them would not be able to fully guarantee against leakage when engaging an outsourcing firm even if that outsourcing firm has an impeccable reputation.
Therefore, there is a need for improved communication security preventing eavesdropping or interception when at least two entities are communicating by means of a VPN connection with management and remote configuration of VPN devices.